Control Tower 管理 CloudTrail をオプトアウトして CloudWatch Logs コストを削減
2024.09.19AWS Control Tower(以降 CT) はマルチアカウント統制で役立つサービスです。 「複数のAWSアカウントを統制するような基盤 (= ランディングゾーン )」を簡単にセットアップしてくれます。
画像: AWS Control Towerを基本から理解する。具体的な活用法を交えて解説 | クラスメソッド株式会社
CT はデフォルトで CloudTrail 証跡を自動で生成、管理してくれます。 aws-controltower-BaselineCloudTrail という名前の証跡です。
マネージドに管理してくれて便利なのですが、 この証跡は CloudWatch Logs にもログを出力 します。 CloudWatch Logs へのログ出力は、S3に比べてコストになるので抑えたい気持ちです。
そこで今回は、この「CloudWatch Logs へのログ出力コスト」を無くすために、 CT管理のCloudTrailをオプトアウト してみます。
前提知識: CT管理CloudTrailのコストについて
先述のとおり、 CTは CloudTrail証跡をマネージドで管理してくれます。 具体的には 管理アカウント上に aws-controltower-BaselineCloudTrail という名前の「組織の証跡(※バージョン3.0 以降)」を作成します。
この証跡の出力先は以下の2つです。
| 出力先サービス | 出力先AWSアカウント | 出力先リソース |
|---|---|---|
| S3 | ログアーカイブアカウント | aws-controltower-logs-{accountid}-{region} バケット |
| CloudWatch Logs | 管理アカウント | aws-controltower/CloudTrailLogs ロググループ |
S3 と CloudWatch Logs 、それぞれでかかるコストを説明します。
S3出力でかかるコスト
S3出力で関連するコストは「CloudTrailの転送コスト」および「S3コスト」です。
「CloudTrailの転送コスト」は1つ目であれば無料コピーとなります。重複を作らない限りは、コストになりません。 コストになっている場合は PaidEventsRecorded という使用タイプで明細が出ます。
「S3コスト」は ログアーカイブアカウントにあるS3バケットへのリクエスト料金と保管料金です。
後述する CloudWatch Logs に比べたらコストは目立ちません。
また、保管料金が増え続ける懸念も大丈夫でしょう。 ライフサイクルルール(N年で失効)が適用されているためです。
CloudWatch Logs出力でかかるコスト
管理アカウントの aws-controltower/CloudTrailLogs ロググループへの出力〜保管でかかる コストの大半は ロググループ取り込み料金(DataProcessing-Bytes) です。
私が関わっている環境では、このコストが S3のものに比べて約10倍ほど高く、 大きなコストになっている状態でした。
オプトアウトにむけて
CT管理CloudTrailは バージョン3.0 以降で「オプトアウト可能」になっています。
要否の検討
そもそもオプトアウトしても問題ないか検討します。
もし 既存証跡を活用した分析・可視化ワークロードを運用している場合は、 移行にあたって準備が必要です。
また、CloudWatch Logs ロググループ自体は、 リアルタイムで特定イベントを検知したり、分析したりしたいときに有用です。 メトリクスフィルターを使ってメトリクス化して、 一連の特定イベントを検知するようなCloudWatchアラームも作成可能です。 こういった活用をしていくのであれば、オプトアウトはしなくても良いでしょう。
今回は以下のような理由でオプトアウトすることにしました。
- 既存証跡に対する大規模な分析・可視化ワークロードは運用していない
- 組織レベルの証跡をリアルタイムで分析することが現状無い
- 不審なアクティビティは GuardDuty で検知できる
- 単発のイベント検知であれば EventBridgeルールで代用できる
計画
CT管理CloudTrail を直接弄って、CloudWatch Logs 出力をOFFにしたい気持ちが正直あります。 しかし、これを実施すると ドリフトが発生して ランディングゾーン管理に支障が出る可能性があります。
そのため、 「カスタムCloudTrail証跡(S3出力のみ)」 を新規に作成して、 「CT管理CloudTrail証跡」はランディングゾーン設定にてオプトアウトする ように進めます。
以下のようなステップを踏んで移行を進めました。
- STEP0: 現状 (CT管理CloudTrailのみ)
- STEP1: カスタムCloudTrail証跡を作成して、N時間待機する
- STEP2: CT管理CloudTrail証跡をオプトアウトする
以降で STEP1, STEP2 で実施した手順を説明します。
STEP1: カスタムCloudTrail証跡を作成して、N時間待機する
S3バケットを作成する
ログアーカイブアカウントに新規S3バケットを作成しておきます。 参考までに展開したテンプレートを以下に記載します。
CloudFormationテンプレートサンプル
AWSTemplateFormatVersion: 2010-09-09
Description: "Create S3 bucket for Organizational CloudTrail logs in ap-northeast-1"
Parameters:
ResourcePrefix:
Type: String
Default: "custom"
S3LoggingBucket:
Type: String
RetentionDays:
Type: Number
Default: 1095
OrganizationId:
Type: String
Default: "o-example"
Resources:
S3Bucket:
DeletionPolicy: Retain
Type: AWS::S3::Bucket
Properties:
BucketName: !Sub ${ResourcePrefix}-cloudtrail-logs-${AWS::AccountId}-ap-northeast-1
# バージョニングを有効化
VersioningConfiguration:
Status: Enabled
# AWS管理キー(SSE-S3) でデフォルト暗号化
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: AES256
# サーバーアクセスログを有効化
LoggingConfiguration:
DestinationBucketName: !Ref S3LoggingBucket
# ブロックパブリックアクセスを有効化
PublicAccessBlockConfiguration:
BlockPublicAcls: TRUE
BlockPublicPolicy: TRUE
IgnorePublicAcls: TRUE
RestrictPublicBuckets: TRUE
# 「N日で有効期限切れ」ライフサイクルルールを作成
LifecycleConfiguration:
Rules:
- Id: RetentionRule
Status: Enabled
ExpirationInDays: !Ref RetentionDays
NoncurrentVersionExpirationInDays: !Ref RetentionDays
S3BucketPolicy:
Type: AWS::S3::BucketPolicy
Properties:
Bucket: !Ref S3Bucket
PolicyDocument:
Version: 2012-10-17
Statement:
- Sid: AllowSSLRequestsOnly
Effect: Deny
Principal: '*'
Action: s3:*
Resource:
- !Sub "arn:aws:s3:::${S3Bucket}"
- !Sub "arn:aws:s3:::${S3Bucket}/*"
Condition:
Bool:
aws:SecureTransport: false
- Sid: AWSCloudTrailAclCheck
Effect: Allow
Principal:
Service: "cloudtrail.amazonaws.com"
Action: s3:GetBucketAcl
Resource:
- !Sub "arn:aws:s3:::${S3Bucket}"
- Sid: AWSBucketDeliveryForOrganizationTrail
Effect: Allow
Principal:
Service: "cloudtrail.amazonaws.com"
Action: s3:PutObject
Resource:
- !Sub "arn:aws:s3:::${S3Bucket}/AWSLogs/*"
Condition:
StringEquals:
aws:SourceOrgID: !Ref OrganizationId
S3バケットには、組織の証跡を配信できるように適切なS3バケットポリシーを設定しておきます。 (※先程の CloudFormationテンプレートでは設定済み)
S3バケットポリシー サンプル
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSSLRequestsOnly",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::DOC-EXAMPLE-BUCKET",
"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "AWSCloudTrailAclCheck",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET"
},
{
"Sid": "AWSBucketDeliveryForOrganizationTrail",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/AWSLogs/*",
"Condition": {
"StringEquals": {
"aws:SourceOrgID": "o-example"
}
}
}
]
}
CloudTrail証跡を作成する
その後、管理アカウントにてカスタムCloudTrail証跡を作成します。 今回は以下のようなパラメータで作成しました。
| パラメータ | 値 |
|---|---|
| 証跡名 | (任意) |
| 証跡の種類 | 組織レベル |
| 証跡ログバケット | (先ほど作成したS3バケット) |
| 証跡ログプレフィクス | なし |
| ログファイルの SSE-KMS 暗号化 | なし |
| ログファイルの検証 | 有効 |
| SNS通知の配信 | なし |
| CloudWatch Logs | なし |
| 記録するログイベント | 管理イベント |
証跡が正常にS3バケットへ出力されていることを確認します。
N時間待つ
この状態で N時間待ちます。 待つ理由は 「特定期間のCloudTrail証跡が無い」事態を避けるため です。
待つ時間については、以下ドキュメントにあるとおり 「最大1日間」を目安にします。 今回は8時間程度にしました。
コストを抑えながら、組織の証跡へのログ配信前にイベントが失われないようにするには、 個々のメンバーアカウントの証跡と組織の証跡の両方を 最大 1 日間 、保持することを検討してください。
STEP2: CT管理CloudTrail証跡をオプトアウトする
管理アカウントにログインします。 Control Tower ランディングゾーン設定ページに移動して、 [設定を変更する] を選択します。
以下ステップを経て、確認画面まで行きます。
1. ランディングゾーンのバージョンを選択→ 何も変えずに [次へ]2. リージョン設定を更新→ 何も変えずに [次へ]3. 設定を更新→ AWS CloudTrail の設定を [有効になっていません] に変更(画像参照)。 それ以外は何も変えずに [次へ]
上記の内容で [ランディングゾーンの更新] を実施します。
ランディングゾーンの更新後、CT管理CloudTrail証跡は すぐにOFFになります。
コスト削減を確認する
後日、CloudWatch Logs コストを確認しました。 以下のように aws-controltower/CloudTrailLogs からの ログ取り込み料金が無くなっているのが確認できます。
移行でかかったコストについて
また、重複させていた期間のコストは PaidEventsRecorded を見ることで確認できます。
考慮事項
GuardDuty通知
CloudTrialをオプトアウトした際ににGuardDuty検知が発生する可能性があります。
特に Stealth:IAMUser/CloudTrailLoggingDisabled 検出結果は、 組織の証跡をOFFにした場合は「組織内の全アカウント」にて検知されます。
セキュリティ通知を実装している場合は、事前に把握・周知しておくと良いでしょう。
ログアーカイブアカウントにあるS3バケットの保護
ログアーカイブアカウント(が所属する Security OU) には Organizations SCPによる予防コントロールが適用されています。 これにより、 CT管理S3バケット( aws-controltower-logs-{accountid}-{region} )が 保護されていました。
今回は新しいS3バケットを作成しました。 必要に応じて、新しいS3バケットにも予防コントロールを適用ください。
参考までにCT管理S3バケットへ適用されているコントロールを以下に記載します。
- 削除を禁止する(GRAUDITBUCKETDELETIONPROHIBITED)
- 暗号化の設定変更を禁止する(GRCTAUDITBUCKETENCRYPTIONCHANGESPROHIBITED)
- ライフサイクルルールの設定変更を禁止する(GRCTAUDITBUCKETLIFECYCLECONFIGURATIONCHANGESPROHIBITED)
- アクセスログの設定変更を禁止する(GRCTAUDITBUCKETLOGGINGCONFIGURATIONCHANGESPROHIBITED)
- バケットポリシーの設定変更を禁止する(GRCTAUDITBUCKETPOLICYCHANGESPROHIBITED)
CloudTrailの保護は大丈夫？ → 基本的には大丈夫そう
ちなみに CloudTrail周りの予防コントロールに CloudTrailの設定変更を禁止する(GRCLOUDTRAILENABLED) があります。 これを「適用しなくても大丈夫か？」という懸念がありますが、 結論から言うと「組織の証跡なので大丈夫そう」です。
メンバーアカウントは組織の証跡を更新する権限を持っていないことが、以下ドキュメントから分かります。
Users with CloudTrail permissions in member accounts can see organization trails when they log into the AWS CloudTrail console from their AWS accounts, or when they run AWS CLI commands such as describe-trails. However, users in member accounts do not have sufficient permissions to delete organization trails, turn logging on or off, change what types of events are logged, or otherwise change an organization trail in any way .
おわりに
Control Tower が管理する CloudTrailをオプトアウトしてみました。
aws-controltower/CloudTrailLogs を使っていない or 使う予定がない環境があれば、 オプトアウトする価値はありそうです。
以上、参考になれば幸いです。
参考
